\documentclass[12pt,a4paper,icelandic]{article}
\usepackage{amsmath}
\usepackage[utf8]{inputenc}
\usepackage{babel}
\usepackage{amsfonts}
\usepackage[T1]{fontenc}
\usepackage{epsfig} \graphicspath{{MATLAB/figs/}}
\usepackage{graphicx}
\usepackage{fullpage}
\usepackage{enumerate}
\usepackage{moreverb}



\begin{document}
\begin{titlepage}
\noindent \\
\vspace{5cm}
\large {
\begin{center}
\begin{huge}
\textbf{Lab assignment mid-term report}\\
\end{huge}
\begin{LARGE}
\vspace{0.5cm}
\textbf{Embedded Computer Architecture - IN4340}\\
\end{LARGE}
\begin{large}
\vspace{2cm}
\textbf{Group 5:}\\ 
Abhimanyu Selvan\\
Bjarni Thor Arnason\\
Mario Voorsluys\\
Quintijn Hendrickx
\vspace{0.2cm}
\end{large}
\end{center}}
\end{titlepage}

\newpage

\section*{Exercise 1}
\subsection*{Solution}
Our parallel version of the given \emph{filter} program first splits the image up depending on the number of threads specified. That is, if the number of threads is X, then the image is split up horizontally into X parts (only the rows are split up but the columns remain whole). A total of X threads are then started and each of them is assigned a section of the image. If the number of threads specified is such that the number of rows can't be split equally between them, then the last thread processes the extra rows.  

\subsection*{Problems}
\begin{itemize}
\item Differences in the filtered image between 32bit and 64bit compiled executables. Two members of our group had 32-bit versions of Linux while the other two had 64-bit versions and the outputs of the filter programs differed. This occured with the parallel code as well as with the original reference code.
\end{itemize}

\section*{Exercise 2}
\subsection*{Solution}
Due to the limited memory available in $\text{RDMA}_0$ of tile 2 we have to process the image 
in several iterations. In every iteration we send 5 rows of the source image to tile2, 
we then copy these rows to local storage in $D_{\text{mem}}$. The image rows get filtered and 
the results are stored in $\text{RDMA}_0$, after all rows have been filtered we transfer the 
data back to the frame buffer.\\
Because we need the rows above and below the current row to process the current row, 
we retain a copy of the last two rows from the previous iteration in $D_{\text{mem}}$.\\
This solution allows us to process 5 rows in every iteration (except for the first 
iteration in which we can only process 4 rows).

\subsection*{Problems}
\begin{itemize}
\item Initially our code did not fit in the instruction memory of the core. Because there is no 64 bit FPU on the MicroBlaze processor the compiler would add emulation code for all double precision operations. This required a very large amount of instruction memory.
\item The size of the RDMA's is restricted to 4kb. Because of this we couldn't filter the image all at once but had to use multiple iterations while sending data back and forth.
\item Waiting for receive and send instructions to complete by using the busy function didn't work. We had to introduce a sleep loop before printing the frame buffer. Without this sleep function the program seemed to print the frame buffer too early, causing unpredictable results.
\item The filtered image of the FPGA still differs slightly from the reference images generated on our computers. About 20-30 subpixels differ by a value of 1 or 2. We suspect this is caused by rounding errors but we are not sure.
\end{itemize}

\end{document}